home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1704 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.9 KB
  1. Subject: Re: Alignment 
  2. Date: Thu, 14 Jul 1994 16:47:29 -0700
  3. From: Howard Chu <howard@harry.lloyd.com>
  4.  
  5.  
  6.   If I cast a const char * such as "MiNT" or "LIVE" to a long *, shouldn't
  7.   the compiler store the string so that it is aligned to a long boundary?
  8.   Otherwise, when trying to read the long at that address, it could be on
  9.   an odd address, and the machine dies.
  10.   
  11.   Lately, that is the way I've been reading strings to compare to cookie tags.
  12.   It has always worked, but when I changed main.c in mint, it crashes and I'm
  13.   pretty sure its because the 68K can't read a long from an odd address.  Is
  14.   this a bug in the compiler, or is such a cast simply bad programming?  If
  15.   this is a bug in 2.4.5 and it will work in 2.5.8, then lemme know and I can
  16.   post the diffs for the cookie jar call and DOM_X (partially implemented).
  17.  
  18. How you use pointer does nothing about what it points to. Just because
  19. you cast a (char *) to a (long *) doesn't tell the compiler that thus-
  20. and-such symbol needs to be longword aligned.
  21.  
  22. Usually the compiler tries to start every data object at an even
  23. boundary, so I'm surprised that you could have made a change that broke
  24. things. The first thing to check whenever you suspect this sort of problem
  25. is to recompile the file with the -S option and look at the assembler
  26. code output. If the declaration of the string in question is preceded
  27. by a directive like ".even" then this can't be the problem, and you'll
  28. have to look somewhere else. If not, then inserting a ".even" in the code
  29. and assembling the file should yield a running program. If that *is*
  30. the solution, then it means you have to change something in the order
  31. of declarations in your C source code.
  32.  
  33. All in all, yes, this is bad programming practice, because it means you've
  34. become dependent on the particular behavior of your linker and other utilities,
  35. and they offer no guarantees about ordering of data objects in memory...
  36.